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Operational Support Systems 


by Robert 0. Aller 

Operations support as considered here is the 
infrastructure of people, procedures, facili- 
ties and systems that provide NASA with 
the capability to conduct space missions. 
This infrastructure involves most of the 
Centers but is concentrated principally at 
the Johnson Space Center, the Kennedy 
Space Center, the Goddard Space Flight 
Center, and the Jet Propulsion Laboratory. 
It includes mission training and planning, 
launch and recovery, mission control, track- 
ing, communications, data retrieval and 
data processing. 

Operations support of NASA’s space 
flight systems during the 1960s and the 
1970s was associated with operations char- 
acterized as Research and Development. 
Flight programs were a single flight of 
limited duration or a series of flights to ob- 
tain specific data or to demonstrate an oper- 
ational capability. This required operational 
support systems to be reactive and respon- 
sive to relatively short duration programs. 

In the past ten years, this has continued 
with some notable exceptions. With ad- 
vances in space and data technologies, the 
demonstrated capabilities and advantages of 
space operations and the increased cost and 
complexity of space systems has led to longer 
duration and repetitive flight programs. Sys- 
tems engineering of operational support sys- 
tems must accommodate this evolution and 
the increasing operational nature of NASA. 

The need for systems engineering is criti- 
cal to NASA in its preparations for conduct- 
ing operations in the late 1990s and into the 
next decade. The planning and implementa- 
tion of the operational support systems for 
this era are under way. Proper systems 
engineering is vital to the development of 
each new system, as well as to a “total sys- 
tems engineering” of the functionality and 
interfaces of the entire operational system. 


Implementation, integration and transition 
of these major changes to the Agency’s oper- 
ational capacity require significant manage- 
ment attention. To assure NASA’s future in 
research, development and operations, this 
system must be implemented successfully 
and designed to minimize NASA’s operation- 
al costs. 

Total Systems Engineering 

The need for incorporation of systems engi- 
neering concepts and discipline is much 
broader for operations support systems than 
the hardware and software systems for 
which it is normally considered. As noted, 
operations support is an infrastructure of 
people, procedures, facilities and systems. 
Although systems engineering is routinely 
applied to each new system, the major prob- 
lems often occur between systems and 
frequently among people, procedures and fa- 
cilities. A disciplined systems engineering 
approach formulating each of these elements 
in the establishment of the “system” cannot 
be overemphasized. NASA has learned many 
times that good system contractors do not 
necessarily nurture good operational person- 
nel and technicians nor do they necessarily 
develop usable maintenance procedures. Ex- 
perience has also shown that facilities not 
adequately analyzed in conjunction with the 
planned utilization of the facilities require 
constant modification to meet operational 
needs. In considering support capability, 
each of the infrastructure elements requires 
analysis and carefully managed selection 
and attention. 

An organizational tier of system analysis 
from the whole to each element can be ap- 
plied in a macro sense to assure consider- 
ation of both technical and nontechnical 
systems. A macro analysis of the system 
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involves many considerations; two nontech- 
nical areas that have often caused problems 
are inadequately skilled personnel and un- 
derdesigned facilities. 

The nature of operations support requires 
a spectrum of talents and skill levels. Most 
newly developed systems have not properly 
analyzed the experience and skill mix need- 
ed nor the number of personnel required, 
which varies from skilled flight controllers to 
maintenance and repair technicians. Too of- 
ten a process to analyze the system operation 
and system maintenance and repair require- 
ments is not properly developed in advance, 
resulting in an operations team that is un- 
dersized and underskilled. 

A second issue is simply undersizing 
facilities. While managers operate on the 
"nature abhors a vacuum” principle and 
insist that each square foot of a new facility 
needs clear functional definition, too often 
new facilities are found to be inadequately 
sized even before they are put into operation. 
This is particularly true with new operation- 
al systems. Facilities should be designed to 
accommodate the unforeseen. Quite often the 
unforeseen is a result of an incomplete 
analysis of the operational and system 
requirements prior to facility design, but 
also new requirements will emerge. A contri- 
buting difficulty is NASA’s facility approval 
process, which is instituted before a reliable 
utilization analysis is available. It is prudent 
to provide capacity for some growth to ac- 
commodate new requirements. 

Another nontechnical factor that is of 
increasing importance to NASA is life cycle 
costing (LCC). NASA has not traditionally 
incorporated LCC as a critical selection, de- 
sign or engineering process. The elements 
critical to LCC have all been managed and 
considered, but an LCC process has not been 
established within NASA or by NASA’s con- 
tractors as a routine process. LCC was used 
as a contract selection factor by NASA for 
the first time in 1988 with the selection of 
the second Tracking and Data Relay Satel- 
lite System (TDRSS) Ground Terminal. It is 


rare that a contractor has an established 
technique to trade and iterate design cost 
against operations costs. LCC needs to be a 
driving discipline to assure that the costs of 
operating the increasingly more sophisticat- 
ed flight systems can be controlled. The 
flight systems of today are projected for 15- 
20 years of operation. This demands that the 
operational support systems be analyzed and 
designed to minimize LCC, or the cost of op- 
erations will increasingly erode NASA’s re- 
sources for new development capacity. 
NASA and its contractors should establish 
more sophisticated models of development, 
operations and maintenance costs that will 
provide more reliable data for conducting 
operations cost trades against alternative 
system designs. 

Systems Engineering and 
Operational Support Systems 

Systems engineering for operational support 
systems follows the traditional disciplines 
applied to the development of major flight 
systems. Operational support requirements 
need to be translated into performance pa- 
rameters and configurations through multi- 
ple iterations to optimize system design. The 
purview of systems engineering includes 
requirements definitions and verification, 
system analysis and design, integration 
planning, requirements control, configura- 
tion control and testing. 

While similar to the design and develop- 
ment of major flight systems, the emphasis 
of the systems engineer for operational sup- 
port systems is generally to provide generic 
support to an aggregate of flight programs 
and the increasing necessity to provide sys- 
tems with extended operational usefulness. 
This operational longevity can be attained 
by systems capable of accommodating 
change while continuing to provide service. 
The Deep Space Network operated by Jet 
Propulsion Laboratory and the Goddard 
Space Flight Network are excellent exam- 
ples of major systems that have provided 
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space flight program support with tracking 
and data retrieval service for 30 years, all of 
the while undergoing changes to provide 
support for increasingly complex missions. 

In addition to providing generic support 
to many users, a vital characteristic of sup- 
port systems is operability. The focus in the 
vehicle development community is principal- 
ly directed toward designing a system that 
optimizes performance; the operations com- 
munity’s focus is directed more toward an ef- 
fective and efficient operation of the system. 
Operability emphasizes ease of operation, 
resistance to system problems and failures, 
maintainability, reparability, simplicity, ef- 
ficiency, capacity for growth and modifica- 
tion, and accommodation of users. 

These two features, multiple program 
support and system operability, are key to 
assuring the proper systems engineering of 
operations support systems. They are 
historically the most difficult to sustain as 
cost and schedule pressures frequently tend 
to compromise the system’s range of utility 
and operability. 

REQUIREMENTS, EVALUATION, 
VERIFICATION AND CONTROL 

Operations systems development is general- 
ly driven by new, expanded or improved 
support service required by new flight pro- 
grams or expanded program objectives. The 
systems engineer needs to challenge user 
requirements to assure the “real” needs are 
not sacrificed at the expense of low priority, 
highly demanding requirements. Occasion- 
ally, requirements are driven by the fact 
that new technology is available and not 
that it is essential (or even desirable) for 
effective operation. The systems engineer 
must consider the broad base of program 
users and not provide a narrow focus of 
support that overly complicates or ignores 
operations of the aggregate of users. 

While sharply defining real needs, it is 
equally critical to consider the potential to 
provide for future capacity. In the informa- 


tion age, the computer (including software), 
communications, and electronics industries 
have developed new technologies and capa- 
bilities often before a flight program s sup- 
port requirements are established. The 
incorporation of these new services needs 
careful examination and scrutiny; when 
these new services clearly enable future or 
expanded programs, however, the operation- 
al community should provide them to 
enhance future operations. An example of 
capability beyond defined need was clearly 
incorporated in the TDRSS program in 1975. 
The TDRSS provides capacity and data rates 
that will meet the requirements of the 1990s 
and well into the next century. It has also 
enhanced flight control concepts by greatly 
increasing the capability to access and con- 
trol spacecraft. If phasing in of added capa- 
bilities can be accommodated, it will permit 
smoothing of resources and help the budget- 
ing process. 

Another important consideration of the 
systems engineer in the evaluation of sup- 
port requirements is the impact these 
services will impose on the user. The goal is 
always to limit the interface restrictions 
imposed on the user program. Two of NASA s 
major operating systems have caused major 
constraints in their use. The Shuttle Pro- 
gram has imposed major safety and integra- 
tion complications on deployed payloads and 
the TDRSS program has imposed scheduling 
and radio frequency interface constraints 
that have been restrictive to some users. 
Some of these constraints with both the 
Shuttle and the TDRSS were intrinsic to 
their operational concepts, but some were 
avoidable, had operability and utilization 
been more completely evaluated. 

When developing systems such as the 
Shuttle and the TDRSS that represent a 
major departure in operating concepts and 
expansion of the operational envelope, the 
systems engineer needs to broaden analysis 
to the entire mission or spectrum of missions 
to better define and limit the major compli- 
cations to system operations and utilization. 
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NASA’s experience with both of these pro- 
grams has clearly indicated much more ef- 
fort is required to operationally understand 
the implications of their use. This experience 
should be understood and applied in the de- 
velopment of the Space Station, the Earth 
Observation System, and their associated 
support systems in consideration of their 
broad utilization objectives. 

Requirements verification and control is 
generally practiced with all new develop- 
ments, but control can be difficult to sustain 
throughout an extended development of an 
operational support system and its oper- 
ational life. Unfortunately, the nature of 
flight programs is to evolve operational sup- 
port requirements and occasionally to trans- 
fer capabilities planned for the flight system 
as requirements to the ground support sys- 
tems. Careful monitoring and control of 
these requirements is essential, particularly 
in the development of software support sys- 
tems. Requirement changes will constantly 
occur, however, and an efficient process to 
identify, approve and control requirements is 
vital. Clear and precise interface definition 
is necessary to enable this control. A detailed 
knowledge of the flight programs that intend 
to use the support system, as well as an un- 
derstanding of other related support systems 
(operational support systems rarely provide 
the total functional support services), is re- 
quired for effective requirements control by 
the systems engineer. Interface definition 
and control are essential to maintaining 
requirements control. 

System Architecture and Software 
Design 

For those operational systems that contain 
standard computers and specialized soft- 
ware, which are a majority of the ground 
systems, a special subset of systems engi- 
neering must be performed to obtain the op- 
timum hardware and software combination. 
The selection of the wrong hardware may 
result in software needs that are difficult 


and expensive to develop. Similarly, less 
expensive hardware solutions may be possi- 
ble when the full range of software abilities 
is considered. (The designer must always 
bear in mind, however, the probable need for 
system expansion, which may make the 
selection of a more complex hardware ele- 
ment the prudent choice since software modi- 
fications are generally less costly than 
computer replacement.) This analysis of 
system architecture may involve the estima- 
tion of size, complexity and structure of the 
software needed for a series of mainframe 
computers. 

Management and the systems engineer 
must realize the definition, design and 
implementation of major software packages 
require the same systems management 
disciplines and controls as do hardware 
components. Because software code can be 
easily erased or changed, it does not follow 
that changes should be considered any more 
lightly than they are for hardware. The 
flexibility associated with software is its 
greatest asset, but if not well managed and 
controlled, it becomes its greatest problem. 
Although software design has made aston- 
ishing progress over the years, software 
development remains a significant problem 
to most major systems. The inability of 
management to accurately predict software 
costs, delivery schedules and performance 
has consistently been a severe problem in the 
development of major operational systems. 

Long-range Requirements 

An area often inadequately considered in 
the design of a support system is its capacity 
for future modification and upgrade as new 
technology becomes available and as re- 
quirements change over time. Many systems 
must continue to provide services while 
undergoing these modifications. Proper con- 
sideration for redundancy and capacity can 
greatly alleviate future expense and compli- 
cations. Making assumptions regarding 
future support requirements can lead to a 
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system design that reasonably accommo- 
dates alternative future growth require- 
ments. Designs that fail to gracefully accom- 
modate change are limited and will lead to a 
dead end. 

While the Deep Space Network and the 
Goddard Space Flight Network have effec- 
tively accommodated change, the initial 
design of the TDRSS ground station failed to 
properly consider the long-term need to mod- 
ernize and upgrade. This required extensive 
redesign and change at significant cost. A 
focus on the current needs may result in 
limited system utility, and pressures to 
implement the least cost system may con- 
strain future expansion and ultimately, be 
the least cost effective. 

The development of new features or major 
changes to operating systems is frequently 
implemented with new contractors. General- 
ly, if NASA and the systems engineer did not 
specifically assure that the original contrac- 
tor provided adequate hooks, the new con- 
tractor’s implementation will be difficult and 
costly. The term “transition phase” is ap- 
plied by NASA to the period when an online 
system is undergoing change while continu- 
ing to provide support services. This is a deli- 
cate and challenging problem to the systems 
engineer and critical in the selection of an 
appropriate design. It is important that tran- 
sition be planned in conjunction with the 
design process and not after the design is 
established. 

In considering long-range requirements 
for operational systems, the type of system, 
the importance of support, and accessibility 
are major factors. These factors were central 
to NASA’s decision and ability to sustain the 
Deep Space Network (DSN) and the Goddard 
Space Tracking Network over their extended 
lifetimes while undergoing numerous modi- 
fications and changes. The continuous avail- 
ability of these sites has been possible 
because of the redundancy within each 
ground station, a configuration of multiple 
sites (redundancy among the ground sta- 
tions), and their accessibility. The recent 


major rebuilding of the 240-ft. DSN antenna 
reflectors prior to the Uranus Encounter was 
feasible because each antenna was sequen- 
tially modified, and alternate antenna 
systems were available at each DSN location 
to provide continuous tracking support. 
Redundancy within the system— provided 
because of the critical nature of tracking and 
communications support — and ground sta- 
tion accessibility have been critical to 
NASA’s ability to continuously operate these 
networks while modernizing their capabil- 
ities. 

When considering system changes, space- 
based operational support systems present a 
different challenge. Two major factors influ- 
ence the consideration to change— accessi- 
bility and cost. Cost is directly related to the 
lack of direct access. Accessibility is difficult 
at best and impractical for most. The Hubble 
Space Telescope is accessible at great 
expense by using the Shuttle but the TDRSS 
satellites are presently inaccessible. The 
systems engineering of space-born support 
systems must consider the criticality of the 
service to be provided, the longevity of the 
service (providing adequate redundancy and 
projected service requirements), and the lack 
of ready access to the system. Satellites can 
of course be replaced by an upgraded satel- 
lite; systems that use multiple satellites at 
multiple locations, however, such as TDRSS, 
require identical satellite configurations to 
provide orbital coverage as an effective oper- 
ational system. Spacecraft replacements are 
normally planned to sustain the system 
through its projected life with no ground in- 
terface and no service changes to the system. 

When new services become necessary, 
they are expensive and require an extended 
period to implement. A space-based system 
that consists of several satellites, such as 
TDRSS, requires a change to the services of 
each satellite in orbit to provide an effective 
orbital service to the user. This is consistent 
with the practice of upgrading all ground 
station locations to the same service configu- 
ration; the accessibility makes the upgrade 
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of space systems more costly and requires a 
much longer time. 

NASA is now planning to modify the 
TDRSS with a higher data rate KA band 
service. The system and budget planning for 
this upgrade was begun in earnest in about 
1985, and it is anticipated the satellite fleet 
will not be in orbit until early in the next 
century, a 15- to 20-year period. The TDRSS 
will have been operating for 20 years or more 
by that time. A similar projection will mean 
the replacement system, Advanced TDRSS, 
will likely be operating to the year 2020 and 
perhaps beyond. It is clear this system will 
be as challenging as the original, with new 
problems replacing those resolved with 
TDRSS. The transition of replacing the 
TDRSS systems presents a significant new 
challenge not faced with initiating the origi- 
nal service. Providing systems engineering 
for the Advanced TDRSS to remain viable 20 
to 30 years in the future will tax any man- 
ager. Systems can no longer be replaced 
frequently or modified to meet individual 
program desires. Careful and complete sys- 
tem analysis and forward-thinking engineer- 
ing are essential to the establishment of 
durable, effective support systems. 

Assuring Operability 

To succeed in developing a support system 
that meets the goals of operability — ease of 
operation, failure resistance, maintainabil- 
ity, efficiency, expandability and accommo- 
dation to users — requires continuous effort 
and emphasis by the systems engineer. An 
oversight and regular review from the opera- 
tor’s viewpoint will contribute to success. 
Both the government and the contractors 
should provide an operational position with- 
in their program management structure that 
is responsible for maximizing the system’s 


operability. Developments that continuously 
focus on the ultimate operation are consis- 
tently superior in performance and in total 
costs. 

The need for NASA to be alert to systems 
engineering is more prevalent now than ever 
before in NASA’s history. The implementa- 
tion of new operating systems is planned 
throughout the 1990s to prepare the agency 
for managing the operations of complex, long 
duration and extremely high data rate pro- 
grams. The quantity of data the agency will 
be processing and managing in the later part 
of the decade was unimaginable in the 1960s 
and the 1970s. This data will be generated 
by programs that will be launched in a 
period when NASA will already be operating 
and supporting a complex array of flight 
vehicles. New ground systems, with evolving 
capabilities and changing interfaces, will 
come into operation almost continuously 
throughout this period. The complex nature 
of interaction among these systems demands 
a visibility and overarching control that can 
only be accomplished through a systems 
engineering network. Management and co- 
ordination of the individual systems is re- 
quired to assure total system functionality, 
interface definition, requirements control 
and the optimization of each system. 

NASA has done an excellent job for the 
past 30 years in providing an operations 
infrastructure that has met the demands of 
exploring space. The next 30 years of space 
operations are equally exciting but represent 
a far greater challenge. The quality of the 
systems engineering of the operations 
support team is critical to both the success of 
the nation’s civil space flight programs and 
to sustaining a viable operational role with- 
in NASA. 



